Security Hub中央設定のポリシー継承ルールを確認してみた
こんにちは。たかやまです。
Security Hub中央設定ポリシーの継承ルールについて考える機会があったので、その内容をお伝えします。
さきにまとめ
- ポリシーは
AND
条件で評価はされず、優先度の高い1つのポリシーのみ適用される - ポリシーは「
アカウント
>子OU
>親OU
」の優先度順で適用される- 同じ優先度のポリシーが適用された場合、後から適用したポリシーが上書きされる
- OUにポリシーを適用している状態から、単一アカウントのポリシーを外す場合は
セルフマネージド
ポリシーを適用する
ポリシー継承ルールについて
まず初めに、ポリシーを適用した場合の継承のルールについて確認したいと思います。
以下はAWSのドキュメントから引用した継承ルールの概要です。
- OU:Root (緑) — この OU は、適用されている設定ポリシーを使用します。 - OU:Prod (青) — この OU は OU:Root から設定ポリシーを継承します。 - OU:Applications (緑) — この OU は、適用されている設定ポリシーを使用します。 - Account 1 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 2 (青) — このアカウントは OU:Applications の設定ポリシーを継承します。 - OU:Dev (黄) — この OU はセルフマネージド型です。 - Account 3 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 4 (青) — このアカウントは OU:Dev のセルフマネージド型の動作を継承します。 - OU:Test (青) — このアカウントは OU:Root の設定ポリシーを継承します。 - Account 5 (青) — このアカウントは OU:Root の設定ポリシーを継承します。これは、その直接の親である OU:Test には設定ポリシーが関連付けられていないためです。
実際に見てみるとわかりやすいと思うので試してみます。
Organizationsは以下のようなOU構成を用意しています。
Root/ ├── 01-Prod/ │ └── Applications/ │ ├── Account1 │ └── Account2 ├── 02-Dev/ │ ├── Account3 │ └── Account4 └── 03-Test/ └── Account5
AWSドキュメントに合わせてポリシーは以下を用意しています。
まずは、RootにRoot-policyを適用していきます。
Rootに適用する場合はすべてのアカウント
に適用することになります。このとき、02-Devはセルフマネージドで管理したいので組織単位またはアカウントを除外
で02-DevのOU IDを指定します。
他のポリシーはOUまたはアカウントごとの適用になるため、特定のアカウント
で対象のOUまたはアカウントを指定して適用していきます。
※執筆時点では組織内で選択
を利用した適用がうまく機能せず、組織単位またはアカウントを入力
を利用することで適用できました
すべてのポリシーを適用した状態がこちらです。
AWSドキュメントに記載されている継承ルール通りポリシーが適用されていることがわかります。
(再掲)
- OU:Root (緑) — この OU は、適用されている設定ポリシーを使用します。 - OU:Prod (青) — この OU は OU:Root から設定ポリシーを継承します。 - OU:Applications (緑) — この OU は、適用されている設定ポリシーを使用します。 - Account 1 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 2 (青) — このアカウントは OU:Applications の設定ポリシーを継承します。 - OU:Dev (黄) — この OU はセルフマネージド型です。 - Account 3 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 4 (青) — このアカウントは OU:Dev のセルフマネージド型の動作を継承します。 - OU:Test (青) — このアカウントは OU:Root の設定ポリシーを継承します。 - Account 5 (青) — このアカウントは OU:Root の設定ポリシーを継承します。これは、その直接の親である OU:Test には設定ポリシーが関連付けられていないためです。
Security Hub中央設定ポリシーの場合は、IAMポリシーやサービスコントロールポリシー(SCP)のように複数のポリシーがAND
条件で評価されるわけではなく、優先度の高い1つのポリシーのみが適用されることがわかります。
また優先度も小さい単位で適用しているポリシーが優先されるようです。
優先度順としてはアカウント
> 子OU
> 親OU
と覚えればよさそうですね。
気になった部分
ここからは個人的に気になった部分についてまとめていきます。
同じ優先度のポリシーが適用された場合
同じ優先度のポリシーが適用された場合、どのポリシーが適用されるでしょうか。
ここではOverride-policy
というポリシーを用意し、Applications OUに適用してみます。
結果としては、後から適用したOverride-policy
が上書きする形で適用されました。
これは不意に既存のポリシーを上書きしてしまうことがないように注意が必要そうです。
Root、OU、アカウントに対してすでにポリシーが適用されていないかは、ポリシーのステータスで確認することができます。
適用済み
のステータスがついている場合は、ポリシーが直接適用されていることを意味します。継承済み
のステータスがついている場合は、親のOUからポリシーが継承されていることを意味します。
AWS CLIで確認する場合は以下のコマンドで確認することができます。
aws securityhub list-configuration-policy-associations
実行例(クリックで展開)
[cloudshell-user@ip-10-130-34-105 ~]$ aws securityhub list-configuration-policy-associations { "ConfigurationPolicyAssociationSummaries": [ { "ConfigurationPolicyId": "a7a0c147-00c8-4b5a-b189-f7aab3137af7", "TargetId": "xxxxxxxxxxxx", "TargetType": "ACCOUNT", "AssociationType": "APPLIED", "UpdatedAt": "2024-02-27T02:13:16.227000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b", "TargetId": "r-0orw", "TargetType": "ROOT", "AssociationType": "APPLIED", "UpdatedAt": "2024-02-27T01:54:43.144000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "4e544185-65dd-40b7-b520-0384cf1ff0ff", "TargetId": "ou-0orw-se15szmr", "TargetType": "ORGANIZATIONAL_UNIT", "AssociationType": "APPLIED", "UpdatedAt": "2024-02-27T03:01:09.828000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "SELF_MANAGED_SECURITY_HUB", "TargetId": "ou-0orw-8ynk65w5", "TargetType": "ORGANIZATIONAL_UNIT", "AssociationType": "APPLIED", "UpdatedAt": "2024-02-27T01:54:35.152000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "5837ef56-98ce-4fab-9cc3-6df992ed42c0", "TargetId": "xxxxxxxxxxxx", "TargetType": "ACCOUNT", "AssociationType": "APPLIED", "UpdatedAt": "2024-02-27T02:13:42.274000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b", "TargetId": "xxxxxxxxxxxx", "TargetType": "ACCOUNT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T01:54:36.326000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b", "TargetId": "ou-0orw-vsolo6ag", "TargetType": "ORGANIZATIONAL_UNIT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T01:54:27.645000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b", "TargetId": "ou-0orw-f768s563", "TargetType": "ORGANIZATIONAL_UNIT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T01:54:27.670000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b", "TargetId": "ou-0orw-44ibzu7z", "TargetType": "ORGANIZATIONAL_UNIT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T01:54:37.561000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "SELF_MANAGED_SECURITY_HUB", "TargetId": "xxxxxxxxxxxx", "TargetType": "ACCOUNT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T01:54:33.568000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "4e544185-65dd-40b7-b520-0384cf1ff0ff", "TargetId": "xxxxxxxxxxxx", "TargetType": "ACCOUNT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T03:01:08.311000+00:00", "AssociationStatus": "SUCCESS" }, { "ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b", "TargetId": "ou-0orw-qxn4ap9x", "TargetType": "ORGANIZATIONAL_UNIT", "AssociationType": "INHERITED", "UpdatedAt": "2024-02-27T01:54:41.562000+00:00", "AssociationStatus": "SUCCESS" } ] }
適用済み
=APPLIED
継承済み
=INHERITED
適用済み
のポリシーがある場合は、継承済み
ステータスのOU、アカウントに影響がでる可能性があるため、ポリシーを適用して問題ないか事前に確認を実施してください。
OU単位に適用するポリシーの内、単一アカウントのポリシーを外す場合
すべてのアカウント
にポリシーを適用する場合は、組織単位またはアカウントを除外
で対象のOU、アカウントを指定することで除外できることをお伝えしました。
一方で、特定のアカウント
でポリシーを適用する場合は、組織単位またはアカウントを除外
の設定項目が確認できません。
(また、セルフマネージドを適用するポリシーを作れるわけでもない)
では、どうやって設定するのかというと組織ツリーから個別にOU、アカウントを選択してセルフマネージドのポリシーを適用することで、ポリシー設定から除外することができます。
除外したいOU、アカウントを選択して編集
を選択します。
個別に管理タイプを設定する画面が表示されるので、セルフマネージド
を選択して設定を保存します。
AWS CLIで設定する場合は、以下のコマンドで設定することができます。
aws securityhub start-configuration-policy-association \ --configuration-policy-identifier SELF_MANAGED_SECURITY_HUB \ --target '{"AccountId": "xxxxxxxxxxxx"}' # アカウントを指定する場合
さきほどの組織ツリーに戻ると、セルフマネージド
のポリシーが適用されていることが確認できます。
ちなみに、セルフマネージド
はアカウントに紐づけられている状態なので、この状態から Account2 をOU移動させたとしてもポリシー継承を拒否してしまう点は注意が必要です。
ためしに、 Root-policy を継承している 03-Test OUに Account2 を移動させてみます。
セルフマネージド
のまま、Root-policyが継承されていないことがわかります。改めて継承できる状態にしたい場合には、さきほどの管理タイプを設定で一元管理
の設定に戻してください。
最後に
ポリシーというとIAMやSCPと同じような評価の仕組みを想像してしまいますが、中央設定ポリシーは他のポリシーとは異なる評価であることがわかりました。
多くのアカウントを管理するOrganizationだと、比例して中央設定ポリシー多くなることが予想されます。
この継承ルールを理解して、適切なポリシー運用を行っていくことが重要になりそうです。
以上、たかやま(@nyan_kotaroo)でした。